Improve some completions on generic object literals#34855
Improve some completions on generic object literals#34855andrewbranch merged 5 commits intomicrosoft:masterfrom
Conversation
|
@typescript-bot pack this |
|
Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at bf0be61. You can monitor the build here. It should now contribute to this PR's status checks. |
|
Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your and then running |
|
Hey @DanielRosenwasser, something went wrong when looking for the build artifact. (You can check the log here). |
|
How do I run this in the playground @orta? |
|
You can't - the trigger for the playground builds is borked - Github's broke some experimental API that was in use (that's what the bot's last comment is on about). |
|
I've triggered it manually: https://www.typescriptlang.org/play/index.html?ts=3.8.0-pr-34855-2 |
andrewbranch
force-pushed
the
bug/34825
branch
from
d59acf3 to
eb702ea
Compare
andrewbranch
force-pushed
the
bug/34825
branch
from
eb702ea to
364a4e0
Compare
sandersn
left a comment
sandersn
left a comment
There was a problem hiding this comment.
Code and behaviour looks correct. Are there existing tests for the no-type-argument case? I expected to see some since the code now only applies in that case.
| ////): void; | ||
| //// | ||
| ////f<'foo'>({ a: { /*1*/ } }); | ||
| ////f<string>({ a: { /*2*/ } }); |
There was a problem hiding this comment.
Why no tests without type arguments? The new code seems to apply exclusively in this case.
There was a problem hiding this comment.
completionsGenericIndexedAccess2 is without type arguments, which tests the primary way that #33937 was a regression. Almost all the existing tests from #33937 / #32100 are without type arguments, but they weren’t complex enough to fail. This test was to ensure that the new clever stuff doesn’t apply when there is an explicit type argument.
6 participants
Fixes some fallout from #33937. Using the intersection was the wrong approach as it led to some nasty effects with conditional and indexed access types:
This is still not a perfect solution, as it offers too many completions in some cases, like this:
I’m planning to iterate on this and hopefully get rid of the invalid ones without un-fixing #30507, but I believe @DanielRosenwasser wants to look at this for 3.7.2.
Fixes #34825